Internet Info 1994 March/Internet Info CD-ROM (Walnut Creek) (March 1994).iso/standards/iso/9660/rockridge/rrg.08

Text File | 1992-08-19 | 11.7 KB | 414 lines

.br
.pn 1
.PH ""
.fp 1 R
.fp 2 I
.fp 3 B
.po 1i
.ll 6.5i
.hy 14
.S 10
.OF "''Page %'October 19, 1990'"
.EF "'October 19, 1990'Page %''"
.ds HF 3 3
.ds HP 13 9
.HM I 1
.SP 1
.br
.S 17
.B
.ce 1
Rock Ridge Group Goals Document
.R
.SP 1
.S 11 14
.H 1 "\ Purpose"
.sp -.5
This document has the following purposes:
.AL a 9 1
.LI
establish and document common goals for group participants
.LI
define a charter for the technical working group
.LI
act as tool for gaining consensus within participating companies
.LI
act as tool for gaining consensus within non-participating companies;
this document may serve as the first formal release from the group
.LI
communicate our group's intentions and interest with respect to the
CD-WO ad hoc group and other groups
.LE
.H 1 "\ Executive Summary"
.sp -.5
The companies participating in the Rock Ridge Group CD-ROM initiative
desire the ability to use a CD-ROM as a\fI complete\fP implementation
of X/Open filesystem directories.  This would allow CD-ROM technology
to be used for
.sp -.5
.ML + 5 1
.LI
software distribution in a heterogeneous environment
.LI
on-line access to CD-ROM executable, data and library files
.LI
database distribution in a heterogeneous environment
.br
without restrictions in a complete X/Open environment
.LE
.SP 1
Today, there is no commonly agreed CD-ROM format for accomplishing these
goals.  The purpose of the Rock Ridge initiative is to create and agree
upon a common format that meets the needs presented above while maintaining
compatibility with the installed base of ISO 9660:88 CD-ROM hardware and
software.
.sp .5
The remainder of this document provides further information on the goals
of the group.
.H 1 "\ Desired Benefits from different viewpoints"
.in 5.5
Publisher
.br
.in 0
.in 8
Provide product distribution via 1 disc to all platforms--
.br
The publisher should not be required to tailor CD-ROM products to
different delivery platforms (PC vs X/Open vs.\ OS/2 servers).
.in 0
.sp .5
.in 5.5
OS Vendor
.in 0
.br
.in 8
Minimize software investment; single initial investment and reduce
ongoing investments.
.br
Allow one software solution which meets all X/Open needs.
.br
Provide full X/Open File information.
.br
Allow future extensions for security purposes.
.br
Discourage ad hoc file format solutions.
.br
Allow current software applications to run without modification
using a CD-ROM.
.br
.in 0
.in 5.5
.bp
Customers
.in 0
.br
.in 8
Allow 1 disc to be used for all types of platforms.
.br
Provide delivery of file data in a heterogeneous environment.
.br
Provide access to all of a disc's data via ISO 9660:88 file data.
.br
Optimize performance for operations involving X/Open extensions.
.in 0
.sp .5
.H 1 "\ \ Motivations for solving the problem co-operatively, not individually"
.br
.in 1.5
Single vendor solutions are no longer a viable strategy in today's business
climate.
.sp .5
Third party X/Open software vendors (ISV's) want to minimize
the business risk of moving to CD-ROM as a new distribution format.
They want a single solution for the open systems market, not multiple
solutions or sub-solutions.
.sp .5
Facilitate ISV expansion to support X/Open systems current DOS and
Macintosh CD-ROM publishers.
.sp .5
Provide the basis for creating an international standard.
.in 0
.H 1 "\ \ \ Definition of terms"
.in 4.5
\'file data\', \'file information\', \'information\' - the data contained within a
file.
.br
\'file attributes\' - the name of the file, dates associated with the data,
permission modes, etc.
.in 0
.H 1 "\ \ Goals"
.AL 1 13 1
.LI
Information interchange
.br
.in +2.4
Maintain the ISO 9660:88 information interchange capability between all
ISO 9660:88 and Rock Ridge systems.
.in 0
.sp .5
.LI
File attribute interchange
.br
.in +2.4
Allow interchange of file attribute information amoung X/Open class systems.
The following file attributes should be supported as defined by
X/Open: UID, GID, mode bits, major and minor device, UID, and GID numbers
by receiving systems shall be provided.
.in 0
.sp .5
.LI
Complete
.br
.in +2.4
The format standard should meet the needs of distribution X/Open file data
and file attribute information.  No additional or optional tagged fields
shall be required to deliver file information required for complete X/Open
systems.
.in 0
.sp .5
.LI
Execution
.br
.in +2.4
The format shall allow direct execution of software from the CD-ROM in a
heterogeneous environment.
.in 0
.sp .5
.LI
Full backwards compatibility
.br
.in +2.4
All file data on discs conforming to these extensions must be accessible on
current Microsoft CD-ROM extensions version 2.1 and other current
ISO-9660:88/level 1 interchange drivers.
.sp .5
.bp
Discs conforming to this specification must meet the requirements of the
proposed XCDR API [Philips]. (Assuming adoption of XCDR by X/Open.)
.in 0
.sp .5
.LI
File names
.br
.in +2.4
Extremely long name lengths shall be possible.  Name lengths as long as
possible shall be handled in an optimal manner.
.sp .5
\`Reader makes right\' interchange: it is the responsibility of the
receiving system to modify names as needed.
.sp .5
Support of ISO 8859/1:87 character set for file names and allow for
support of future character set standards.
.in 0
.sp .5
.LI
Path names
.br
.in +2.4
Extremely long path names shall be possible.
A system independent method for defining pathname components shall
be provided.  There shall not be any limitations on directory depth.
.in 0
.sp .5
.LI
Application Programming Interfaces
.br
.in +2.4
No impact on X/Open system APIs including XCDR.  If necessary, an
additional API will be proposed.
.in 0
.sp .5
.LI
Service Interfaces
.br
.in +2.4
Same as the following sections in XPG 3 v2 [88].
.br
2.1.19 Directory
.br
2.1.20 Directory Entry including symbolic links
.br
2.1.26 Empty Directory
.br
2.1.32 File
.br
2.1.33 File Access Permissions
.br
2.1.37 File Hierarchy
.br
2.1.38 File Mode
.br
2.1.39 Filename except, allow lomger names. See VI.6.
.br
2.1.43 File Permission Bits
.br
2.1.46 File Times Update as defined for read-only filesystems
.br
2.1.71 Portable Filename Character Set-- use XPG 3 specified ISO 8859/1
character set except no reserved characters
.in 0
.sp .5
.LI
Performance
.br
.in +2.4
The format shall be optimized for on-line access to a disc's executable,
data and library files.  In addition, the format shall optimize for
directory information access.
.in 0
.LE
.bp
.H 1 "\ \ Non-Goal"
.sp -.5
.in 4.5
Common Application data format.  We do not seek to define a common data
format.  For example, requiring ASN.1 descriptions of file data.  Binary
executable formats are also outside the scope of the Rock Ridge Group.
.in 0

Reference
.TS
expand;
l lw(5.3i).
[Philips]    T{
.ad b
X/Open CD-ROM Support Component (XCDR). Version 2, June 1990.
This document is available from Hans de Jong, Philips Information
Systems.  Telephone [phone].
T}
.TE
Appendix

The appendix contains additional information that may be of interest
to the reader.

Discussion of information interchange goal.  Reference: VI.1.
.br
We define two types of information interchange between platforms.
.br
.in 4.5
Alternative 1 - Common file system format and all file data can be read
by all platforms.
.br
Alternative 2 - Common file system format and all file data can be read
by some platforms.

Alternative 1: This type of interchange maintains the original ISO 9660:88
concept of \"...[enabling] information to be interchanged between
different systems...\" [Section 1, ISO 9660:88].

This type of data interchange assures the accessibility of files in a
heterogeneous work group environment.  Any type of platform connected
to a common LAN would be able to access all of the information on a
disc, no matter the type of disc server.

This type of data interchange encourages the creation of \"open\"
applications whose data is available to all users.

Counter argument: some architects feel that it would be desirable for
the file labeled \`start\' to refer to different file information
dependent on the machine type or architecture.  The user would only
have to invoke \`start\' no matter his or her machine type.

But this would make information inaccessible in many circumstance.
In addition, the same effect can be gained within the X/Open market
by writing a single \`shell script\' which used the uname(1) command to
execute the correct binary file.

It may be difficult or impossible for a common shell script to probe
for and correctly handle the needs of X/Open, DOS, and other types of
systems.
.bp
Alternative 2:  This type of interchange would allow the CD-ROM to
contain files which are available to soem but not all types of receiving
platforms.  For example, in a network environment, an X/Open platform
which acted as a server might not be able to export DOS files on a
CD-ROM disc to the networked DOC PC's since the files would be
invisible to the X/Open platform.
.in 0

Discussion of File attribute interchange goal.  Reference: VI.2.
.br
.in 2
UID and GID mapping between values stored on the disc and values used by
a particular X/Open system are defined by the XCDR proposal.  Per section
VI.5, XCDR's mechanisms shall be used whenever possible.
.in 0

Discussion of Execution goal.  Reference: VI.4.
.br
.in 2
Execution of software directly from a CD-ROM disc without first copying
the software to magnetic disc is desirable for several reasons:

Ease of use: no installation of the software onto magnetic disc means that
the use can \"load and go\" his or her software.  By providing a complete
By providing a complete runtime environment on the CD-ROM, a publisher can
reduce the complexity of installations.  This application would not have
to be adapted to a specific system's file layout.

Ease of documentation: A CD-ROM can contain many software packages which
are frequently used or which are meant as demonstration/trial applications.
Direct execution allows the user to demonstrate or use low-usage applications
without having to load then unload an application each time it is used.
.in 0

.in 4
No consumption of magnetic disc resources: often, magnetic disc resources
are highly constrained on an operational system.  Direct execution from the
CD-ROM means that magnetic disc space does not need to be planned,
allocated or consumed before using software.
.in 0

Discussion of Backwards compatibility goal.  Reference: VI.5.
.br
.in 2
Backwards compatibility with current ISO 9660:88 hardware and software
is required for the following reasons:
.in 0
.br
.in 4
It is unrealistic to expect that the embedded base of current CD-ROM
drives will be updated to take advantage of a new CD-ROM format
specification.  Discs produced using this specification must be readable
by the installed base or publishers will not make use of it.

Maintaining compatibility will reduce ISV concerns about migrating to
use a new disc format.

Publishers wish to leverage their ISO 9660:88 experience and expertise.
.br
.in 0
.bp
Discussion of File name goal.  Reference: VI.6.
.br
.in 2
Character and byte counts may be different when a multibyte character set
is used.
In particular, the \`space\' and \`solidus\' (/) characters may be used
without restriction in file names.  Also, any number (including none)
\`full stop\' (.) characters may be used.
.br
Character names are from ISO 8859/1:87.
.in 0

Discussion of Path names goal.  Reference: VI.7.
.br
.in 2
Path names shall not be stored as a single character string that
reserves some character such as \`solidus\' (/) as a separator.
Directory depths for X/Open systems are often very deep.  For example,
the widely used X11 window system from MIT includes directories that
are 11 steps deep.
.in 0

Discussion of Performance goal.  Reference: VI.10.
.br
.in 2
Directory information access should be optimized by physically
placing all directory informaton in one area.  Directory
information (file dates, etc) should not only be physically near
near the file information.
.in 0
.br